Appi. No. 10/700,206 
Amdt. dated June 9, 2008 

Reply to Office action of January 10, 2008 and Advisory Action of April 23, 2008 

REMARKS/ARGUMENTS 

Claims 1-13 remain in this application. 

The Examiner has rejected Claim 1 1 under 35 U.S.C. 101. Claim 1 1 has been amended 
to obviate this rejection. 

The Examiner has rejected Claims 1-13 as being unpatentable over Bakre in view of 
Shionozaki. Applicants respectfully traverse this rejection. 

Referring to Bakre, there is disclosed a switch-based network architecture for IP multicast 
and integrated services. Bakre is directed to mapping IP and different levels of quality of service 
over an ATM network. Bakre, which is based on multicast switches, allow RSVP applications 
running on an ATM host to seamlessly participate in Internet wide multicast sessions. See 
column 1, lines 8-19. 

Bakre teaches a network architecture is constituted by one multicast switch per logical IP 
subnet in an ATM cloud. The multicast server in an ATM network allows aggregation of traffic 
for multiple senders that can be sent out on a single VC to the receivers. The multicast server is 
also capable of processing RSVP control messages in performing call emission control for RSVP 
flows. On the edges of the ATM cloud, border or edge multicast switches help to aggregate 
multicast receivers inside the ATM cloud for outside servers and vice versa. See column 8, lines 
47-65. 

Each multicast switch can communicate with all other multicast switches in the ATM 
cloud using a point to multipoint VC. The multicast switches constituted by switch hardware and 
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a switch controller that can establish the translation tables for cell forwarding. A multicast 
routing component of the multicast switch consists of three parts. The first part is responsible for 
maintaining group membership information for the logical IP subnets. The second part is 
responsible for communicating with its peer functions running another multicast switches in the 
ATM cloud. The third part of the multicast routing component provides an inter domain 
multicast routing protocol interface to IP routers located outside the ATM cloud. See column 9, 
lines 45-60. 

All the multicast switches in an ATM cloud initially form a mesh of point to multipoint 
among themselves. Once the control VCs are established, multicast forwarding within each 
logical IP subnet is performed as follows. A multicast address resolution server is employed in 
each logical IP subnet to resolve an IP multicast address to ATM addresses of the receivers that 
have joined the group represented by the multicast address. The multicast switch aggregates 
receivers within its logical IP subnet for outside sensors and outside receivers for local senders. 
To initiate quality of service-based multicast, a sender starts sending path messages to its local 
multicast switch. These path messages are formed over the improper and inter-logical IP subnet 
control VCs by the sender of multicast switches. Multicast switches combine the resource 
reservation requests from their local receivers and send an aggregate message to the senders 
multicast switch. The senders multicast switch collects requests from other multicast switches 
and its local receivers and forms an aggregate request to the sender. 

Reservations among multicast switches are handled using ATM signaling protocols, thus 
allowing the ATM network to best manage the quality of service and the path to multicast 
switches to multicast switches point to multipoint VCs. An RS VP soft state is maintained by the 
RSVP handler function of each multicast switch. RSVP requires routers to monitor RSVP flows 
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using inactivity timers and discard the state for flows that have not seen any traffic for a 
configured amount of time. 

As is evident from the above description, the entire teachings of Bakre are centered 
around and require a multicast switch in regard to an ATM cloud. The teachings of Bakre really 
have nothing at all to do with applicants' claimed invention. Furthermore, the Examiner cites 
figure 4, reference 16 as support for the limitation of sending connections to the network, with at 
least one of the output mechanisms nonmodifiable. However, referring specifically to figure 4 
and reference 16, it refers to a logical IP subnet control VC which emanates from its respective 
multicast switch to its respective ATM host. Referring to the text regarding figure 4, Bakre 
simply teaches that in figure 4, all the multicast switches and ATM cloud initially form a mesh of 
point-to-multipoint control VCs. Propagation of control messages from a multicast switch to the 
multicast receivers within the logical IP subnet is handled using separate point to multipoint 
control VCs 16. This inter- logical IP subnet control VC 16 is routed at the multicast switch in 
every multicast receiver and is added to the control VCs 16 as a leaf node when it first registers 
as a receiver with the local Mars for any multicast group. 

In regard to the Advisory Action, the Examiner essentially refers to column 16, lines 
24-45 of Bakre for support of the limitation in Claim 1 of applicants that at least one of the 
output mechanisms are nonmodifiable. However, Claim 1 has the limitation that the controller 
dynamically modifies parameters for the connections of the fabric, the output mechanism, and 
the plurality of the output mechanisms based on the modify signal. It is only the output 
mechanism which is non-modifiable that has its connection or connections destroyed and then 
re-created. 
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Bakre specifically teaches that RSVP allows receivers to change their QOS reservations 
at any time even after a multicast session has been established. It is somewhat difficult to 
support dynamic quality of service and ATM networks. The only possible way to change quality 
of service for an existing data VC in the ATM network is establish a new VC with the modified 
quality of service parameters and migrate traffic from the old AC to the new one. See column 
16, lines 24-32 of Bakre. This is in direct contrast to applicants' claimed invention where the 
controller dynamically modifies parameters for the connections of the fabric, the input 
mechanism, and the plurality of the output mechanisms except for the non-modifiable output 
mechanism based on a modify signal. Except for the connections of the nonmodifiable output 
mechanism, applicants 1 claimed invention does not establish any new connection, as is taught by 
Bakre. It is respectfully submitted, the term "dynamically" means to change that which exists, it 
does not mean to destroy. Where the output mechanism cannot be dynamically changed, then the 
connection is destroyed and re-created in applicants' claimed invention. Accordingly, Bakre 
teaches away from any type of dynamic modification of parameters for connections, and 
furthermore does not teach or suggest the use of a modify signal to cause the dynamic change. 

Furthermore, applicants' invention of Claim 1 specifically has the limitation of switching 
permanent virtual connections. Applicants have taken the time in the specification to explain 
carefully, starting on page 7, line 14 the distinctions regarding permanent virtual paths and soft 
permanent paths. There is no teaching or suggestion that Bakre has any capability, let alone 
need, or concern of switching permanent virtual connections. 

In regard to Shionozaki, the Examiner has simply cited Shionozaki for establishing 
releasing connections for SVC and PVC. However, there is no teaching or suggestion 
whatsoever how the establishing and the releasing of connections of SVC and PVCs taught by 
Shionozaki would be effected in some form or fashion by Bakre. It is respectfully submitted the 
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Examiner is finding some arbitrary reference that has the teaching the Examiner recites, and 
simply applies it to Bakre to arrive at applicants 1 claimed invention. It is respectfully submitted 
this is using hindsight, which is improper and patent law. Applicants respectfully submit they 
did not discover permanent virtual connections or switched virtual connections, as found in 
Claim 8, but applicants submit that in the context of the switches as found in the claims, they are 
unique in handling or dealing with permanent virtual connections or switched virtual 
connections. 

Accordingly, Claims 1-13 are patentable over the applied art of record. 

In view of the foregoing amendments and remarks, it is respectfully requested that the 
outstanding rejections and objections to this application be reconsidered and withdrawn, and 
Claims 1-13, now in this application be allowed. 

Respectfully submitted, 
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